Follow-up to my earlier review: I think there is one more reliability gap in the offscreen transport.

In background.ts, the ws-message branch sends sendResponse({ ok: true }) immediately, before handleCommand() finishes and before the result is sent back to the daemon. In offscreen.ts, flushPendingFrames() treats that ok as delivery success and removes the frame from pendingFrames right away.

That means "accepted by the Service Worker" is currently being treated as "fully delivered", but those are not the same thing. If the SW is interrupted after the early ack but before handleCommand() completes or before wsSend(JSON.stringify(result)) reaches the daemon, the daemon never gets a response and the offscreen queue will not retry, because that frame has already been shifted out.

So this still leaves a command-loss window exactly in the path this PR is trying to harden. I would suggest either:

• delaying the ack until the result has been sent back successfully, or
• introducing a separate completion ack / correlation mechanism instead of dropping the frame on initial receipt.

There is a second loss path on the return leg as well. In background.ts, wsSend() treats offscreen delivery as best-effort: if chrome.runtime.sendMessage({ type: 'ws-send', ... }) comes back with { ok: false } because the offscreen WebSocket is not open yet, it just triggers offscreenConnect() and returns without buffering or retrying that payload. So even when handleCommand() itself succeeds, the result frame can still be dropped if the daemon connection blips between command receipt and response send.

That means the current design can lose commands in both directions: once on the early ack path, and again on the result-send path. I think the response payload needs the same durability treatment as incoming frames, not just a reconnect side effect.